The present invention relates to data compression and decompression in a data network and more particularly, relates to a system and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks.
In recent years, increased usage of the Internet has resulted in scarcity of network capacity, and compromised performance of traditional applications. At the same time, new applications such as interactive audio and/or video, including video-conferencing or Voice over IP (VoIP) have emerged which demand timely data delivery and much improved quality of service. Real-Time Transfer Protocol (RTP) has been used to obtain inter-operability among different implementations of network real-time applications such as video-conferencing and Voice over IP. For Internet Protocol (IP) based real-time multimedia, RTP may be used on top of User Datagram Protocol (UDP/IP) to make use of multiplexing and checksum services as described in the xe2x80x9cRTP: A Transport Protocol For Real-Time Applicationsxe2x80x9d by Henning Schulzrinne, Stephen L. Casner, Ron Frederick, and Van Jacobson, Request For Comments (RFC) 1889, January 1996. However, there is concern that RTP headers may be too large for acceptable interactive response and line efficiency, when operating over low speed lines such as dial-up modems. For example, in the Internet Protocol version 4 (IPv4), header fields including IP/UDP/RTP may occupy 40 bytes per packet. Likewise, such header fields may occupy 60 bytes per packet in the Internet Protocol version 6 (IPv6). This header-overhead is quite considerable in real-time applications such as conversational voice where the actual voice payload may be as little as 36 bytes (corresponding to 20 ms of GSM coded voice). As a result, such header-overhead needs to be significantly reduced for real-time applications.
Currently, there are few header compression techniques available to compress headers of IP/UDP/RTP datagrams in order to reduce the header-overhead and allow efficient use of bandwidth on low and medium speed links. Most recent example of such header compression techniques is described in the xe2x80x9cCompressing IP/UDP/RTP Headers For Low-Speed Serial Linksxe2x80x9d by Stephen L. Casner, and Van Jacobson, RFC 2508, February 1999. A header compression mechanism is provided with a compressor/de-compressor for compressing headers of IP/UDP/RTP datagrams to reduce header-overhead to 2-4 bytes. The header compression scheme is based on the observation that most fields of the EP headers remain constant in a packet stream over the life of the connection (i.e., length of a session). Therefore, header compression may be achieved by maintaining a compression state at the de-compressor and by simply transporting a minimal amount of header-overhead (such as a session context identifier and a small sequence number used for error and packet loss detection) from the compressor to the de-compressor. According to RFC 2508, the compression state at the de-compressor may correspond to uncompressed header fields including those that change in every packet and those that do not change in every packet. For the non-changing fields (such as source and destination IP addresses and port numbers), the de-compressor may simply add the corresponding fields stored in the compression state. For the changing fields, however, the de-compressor may rely on the information sent in the compressed packet header. Typically, the information contained in the compressed packet header includes the difference in change with respect to the value of the field in the previous packet (i.e., only non-zero second-order differences of changing fields), and does not include the changed field itself.
For general operation, the compressor starts off by sending full IP/UDP/RTP headers to the de-compressor until the de-compressor establishes a context state for the non-changing fields as well as the first-order difference(s) for the changing fields. Once the context state is established, the compressor need not send the first-order differences (especially those corresponding to RTP header fields such as RTP timestamp and RTP sequence number) unless the second-order difference (delta) is non-zero. When the second-order difference (delta) of the RTP header from packet to packet is zero, the de-compressor can reconstruct a packet without any loss of information by simply adding the first-order differences to the saved uncompressed header representing the previous packet as each compressed packet is received. All that needs to be communicated is a session context identifier (ID) and a small sequence number (not related to the RTP sequence number) in order to maintain synchronization and detect packet loss between the compressor and de-compressor. For example, if the RTP timestamp changes from 20 to 40 to 60 for packets #1, #2 and #3, the first-order difference between 20 and 40 and between 40 and 60 is 20. When the initial value of 20 is known, the de-compressor may simply add the correct increment for packet #3 if an appropriate field in the compressed header indicates that the second-order difference is zero.
On the other hand, if the second-order difference (delta) of the RTP header is not zero for some fields, the new first-order difference for just those fields must be communicated using a compact encoding. The new first-order difference values are added to the corresponding fields in the uncompressed header in the session context of the de-compressor, and are also stored explicitly in the session context to be added to the corresponding fields again on each subsequent packet in which the second-order difference (delta) is zero. Each time the first-order difference changes on subsequent packets, that difference is transmitted and used to update the session context.
However, the header compression scheme as described in RFC 2508 and other RFC documents which contain Internet Standard protocols available to the Internet community are not suitable for operation in environments (such as cellular wireless networks) where bandwidth is at a premium and there are high link errors and high link latencies. The loss of a packet can force the de-compressor to append incorrect header information, such as RTP timestamp and RTP sequence number, to the next successfully received packet. Similarly, if a compressed packet header is in error, similar incorrect reconstruction of an RTP packet can result. For instance, if a packet containing the new first-order difference for a field (or multiple fields) is considered lost (perhaps due to errors), the headers for the subsequent packets cannot be correctly reconstructed until the de-compressor has notified the compressor, and the compressor has successfully re-transmitted the required first-order difference. During this recovery phase, the packets already transmitted and in transit cannot be operated upon for header reconstructions. For real-time applications, such as Voice over IP (VoIP) and Video Conferencing, those packets may be discarded due to the expiration of play-out deadlines. For example, consider a cellular link that has a 60 ms one way delay from the radio access point (such as a base station) to a mobile station (or 120 ms round-trip delay from base station to mobile station and back to base station), and an inter-packet separation between voice packets is 20 ms during a talkspurt. At the start a talkspurt, the RTP timestamp of the very first packet usually increments such that its second-order difference is non-zero due to the silence interval. Therefore, a new first-order difference has to be communicated to the de-compressor in this very first packet. If the packet is somehow lost due to errors, the following three packets (60 ms/20 ms) cannot be reconstructed until the de-compressor informs the compressor about the failure, during which time another three packets would have been transmitted by the compressor (assuming that a talkspurt lasts for at least six packets). All these six packets have to wait until the correct first-order difference is received by the de-compressor, and as a result, may be discarded due to play-out deadline expiration.
Accordingly, there is a need for a robust IP/UDP/RTP header compression scheme in the presence of unreliable networks. In addition, needed is a scheme that can correctly reconstruct headers in the presence of packet losses and errors.
Accordingly, various embodiments of the present invention are directed to a robust IP/UDP/RTP header compression mechanism and technique that can correctly reconstruct IP/UDP/RTP headers in the presence of packet losses and errors. The header compression mechanism includes a compressor/de-compressor implemented for operation similarly to RFC 2508 but designed specifically to address robustness when employed in lossy and error-prone networks to correctly reconstruct headers in the presence of packet losses and errors.
In accordance with one aspect of the present invention, the robust header compression scheme requires that, when a second-order difference of a field is non-zero, not only a particular RTP packet whose second-order difference is non-zero is sent with the new first-order difference, but also those following packets are also sent with the new first-order difference as long as: (a) a period pre-determined by factors such as channel characteristics (e.g., link round-trip time RTP/inter-packet separation); or (b) a positive confirmation is received by the compressor that the new first-order difference has been correctly received. This will ensure that even if the packet that caused the second-order difference to be non-zero is lost, the following packets are xe2x80x9cself-containedxe2x80x9d so that the de-compressor can correctly reconstruct their headers.
In accordance with another aspect of the present invention, the robust header compression scheme requires that, if the corresponding RTP field changes again with non-zero second-order difference during the period of communicating the first-order difference, the xe2x80x9cnewxe2x80x9d first-order difference is combined with the original first-order difference such that the two first-order differences may be appended together as a simple means of communicating the two first-order differences reliably. However, the present invention does not preclude other means of combining the first-order differences for efficiency purposes.
The present invention is more specifically described in the following paragraphs by reference to the drawings attached only by way of example.